技术方案，不是后端才需要写么？为什么前端也需要？有必要么？

不管如何，一个需求的实现所使用的技术方案受限于这个人的具体的技术水平，这个是不可变的。

那么在这个人的技术水平里有明显的几点会影响这个方案本身，比如：

从文档也是研发重要交付产物的理念里，我们知道文档是非常重要的部分，而技术方案是从需求到产出代码的桥梁，也是我们发布评审或者代码评审的依据。

良好的技术方案设计，是产品全流程开发中重要的组成，也是产品持续稳定迭代的基本保证。

描述需求背景，可以借鉴产品的描述。

对其中的产品名词进行理解和进一步阐述，包括语义化的和专业化的。

基本排期，责任人：

此次技术方案的所有的参考文档，作为本次方案的理论基础，选型基础。

备注：包括但不局限于官方文档，团队内文档，团队外文档，相关说明等

针对业务流程，画流程图；

针对复杂的领域模型的状态变化，画状态图；

针对不同领域的交互，画泳道图；

针对复杂的技术方案，画架构图，流程图，类图等；

针对复杂的交互，画或者完善用户交互图；

针对每个任务给出基本的细分，并给出基本的时间，接口，备注内容，是否有待确定项。

任务拆解表格：

备注：

1 buffer系数可以参考我的相关文章：链接

2 接口的联调时间可以参考我的相关文章：链接

api设计：

注意事项：

1 无论队列还是日记，内外输出的都是对象的格式，不需要存储方案或者业务方做格式转化

2 初始化中，传入的日记id，可以用于方法中获取日记以及删除日记时，直接从实例化中取值，减少参数传递

3 提供单例模式，降低使用成本

4 理论情况下，只建议用户通过存储管理的方式进行日记的增删改查

\

为了方便描述或者交接自己的成果，建议研发针对相应的测试用例整理出自己的技术方案细节是什么（伪代码）。

比如：

如果你对前端如何写技术方案不清楚，或者对系分之后如何复盘不清楚，可以关注参考我的相关语雀文档：链接